Now let's actually save the data from the leaderboard to the data store.
We initialized it, but we haven't saved anything that we've obtained in the game.
Let's go down below initialized player data and above our player added.
Want to add another function?
Local function save player data and then we will have the player get passed in.
I'm going to get a data, a data variable.
Just initialize it to an empty table right now.
And then I'm going to get my data points from player leader stats, dot points, dot value.
I'm going to do three of these.
Write control.
C control V control V one is going to be kills, one is going to be Dats doesn't have doesn't matter
what order kills, but doesn't matter about spelling.
So make sure you spell these right.
And kills here.
Deaths.
Oh, my goodness.
There we go.
Deaths.
Deaths there.
And then we're going to do our DS set async for our player user ID and just pass in the data.
So we're going to get all the stuff from the leader stats and then put it in this data structure, this
data table right here and then save it off.
But we also want to save things intermittently as the game runs just in case something weird happens.
Let's do this local function save loop and I'm going to save the data for all the players.
Periodically.
I'll do a while and I'm going to do it for 5 seconds because this is a demo you might actually want
to make it like every 30 seconds or something.
Do so while wait five 5 seconds do local players is going to be my player service.
I'm going to do a game dot players, colon, get children.
It's going to get all the players in the game.
They'll do a for loop for I and player in pairs from our players right that's the group of players do
we'll get our board let's check to see if there's a board because there might not be right We start
initializing players and doing things prior to the board being added.
This is going to fire for everybody in the game, not just the player being added.
So it's possible you get a player that doesn't have a board.
Let's check to make sure they have a board because we're using it for saving stuff.
So we'll just say leader stats, right?
We're going to get the player, we're going to do a fine first child for leader stats, make sure they
have the board.
If board, then we'll call this save player data for that player
and we can print two, right?
So we do a print print in save loop in save loop for player and you'll want to get rid of this because
if you have like 50 players is going to loop for everybody.
Player dot name.
It'll be good for testing though.
You know what I'm going to do?
I'm just going to put a little bit weight in between there because we are making calls to the data store,
maybe slow down the network traffic a little bit.
All right.
So where do we call this and where do we call this?
Well, this one we definitely want to call it when there's a player being removed from the game.
Right.
So let's copy that.
So we keep it in mind.
I'm going to do this.
I could do this below.
Player added.
I think I will.
Let's go down to the bottom, the very bottom of the script game players player removing.
So that's when a player is being yanked from the game or one leaving the game.
Right When they're leaving the game, connect save player data and the player will get passed in as
an argument because it's much like Player added.
So the player that's being removed is going to have the variable in sent to save player data.
Now, one thing to keep in mind when you're leaving Roadblock Studio, this might not fire fast enough
because Roadblock Studio shuts down right away, so the player removing will be fired.
You might not save data when testing if that's really important to you.
You should look up something called bind to close.
Bind to close fires when the server is shutting down so that you could make sure you get one last save
in there.
And it's good for studio testing, but in actuality you're really only going to have to watch the player
removing event.
You're just going to have to be careful when you're doing your test in studio that this might not save
everything.
All right.
So we have that firing when somebody leaves, we need to get this going.
So I think what I'm going to do is copy, maybe do a control C for that.
And we only want that to start one time.
Like not every single time a player enters, maybe just on server startup.
So let's do a spawn save loop and this is going to spawn off of a thread for the save loop and it should
only happen on server startup when people join our game.
This is going to happen every time someone joins the game.
We don't need that many.
We don't need that many calls to our our save loop because it is already calling all of our players.
Let's go ahead and give it a try, see if we can get some data going now and save it off in between
our in between our games.
We're going to get a couple of coins maybe, and then die.
Maybe two.
Let's see.
We can't do kills because we only have one player.
We can die, though.
Let's try that.
Bam.
So we got a death.
And we can get.
What was that?
That was my head.
We can get a we can get a zombie.
Two or a coin.
Let's get a coin.
We got our gun.
So we got ten points there.
20 points, maybe 30.
So we got 30 points and we got one death.
Let's take a look at our output window.
Remember, we may not be able to save as we're leaving because the player removing event doesn't fire
fast enough for the studio to shut down.
It will for regular for regular servers in your game.
But we're getting all kinds of these calls that the data store data store request was added to the queue.
All right.
Let's go ahead and shut down.
We're all shut down.
Let's go ahead and play.
And there we go.
30 points.
One death.
That's looking good.
Now, there's a couple of things you need to keep in mind.
We tested our data store in Roadblock studio for our player.
If you play that player in the game in roadblocks on a legit roadblocks player in a regular game, that
date is still going to be there.
The data store is not test test data store data, it's the actual data store.
So if you mess up your data in Roadblock studio, you're going to mess up your data in the game.
Now, the test server data, although it is the same data store, same as the production game, your
user IDs are different.
They usually make it like negative one and negative two.
I don't know if they change that anytime soon.
Probably they change a lot of stuff in roadblocks, but if we test under the test server, we're going
to not we're not going to be able to see the results if we play in regular studio, not with the test
server or in the game.
And I'm going to demonstrate because that's really hard to explain.
I'm going to pause the video.
All this is starting up.
All right.
So I got him down to almost dead.
And there we go.
So we got to kill.
And other player got a death.
Let's shut this down.
Bring it up.
See if we maintained our leaderboard.
I'll pause the video again.
Shut it down.
Bring it up.
You can see I'm going to do clean up right here.
And we got it right.
We got our one kills and one death.
Now he's at 50 points.
One kill, one death.
What happens if we close this all out and start up our regular or regular test server on Roadblock studio?
Not the under the test tab.
So if we go here, try this out.
We have our original 30 points one deaths with no kills.
So you can see that they use different IDs on this test tab for this server right here.
So that actually is considered the test server.
This isn't the test server, this is roadblock studio testing.
So keep that in mind When you start doing the test server with a different players, your user IDs are
going to be like negative one, negative two, negative three.
And this is the actual player user ID when I just hit the test right here, the play button right here
in Roadblock Studio.